Technote Number: 1084985
Problem:
SCENARIO 1: Working on a single machine.
This issue was addressed by Lotus Software Quality Engineering in Notes 5.0.9a
and Notes 6.0.
Excerpt from the Lotus Notes and Lotus Domino Release 5.0.9a MU fix list:
Client - Editor
SPR# TKAA4DB8UR - Fixed a problem which caused a document created in backend
LotusScript not being marked as read when opened with ws.editdocument and then
saved in the UI.
SCENARIO 2: Working on multiple machines.
This is working as designed. By default, unread marks are not replicated;
instead we rely on a journaling feature on the workstation to synchronize
unread marks as different replicas of the same database are opened. When
multiple machines are utilized, the unread status could be lost on a document
since the journal will not be able to play back against all replicas. For
further details on how to address this by forcing unread marks to synchronize
on replication, use the NOTES.INI parameter REPLICATOR_SYNC_UNREAD, as outlined
in the document titled "Unread Marks Are Not Exchanged Replicating to a Server
From Two Different Clients (#158903 ).
SCENARIO 3: Leaving Replica open.
This issue was addressed by Lotus Quality Engineering in Notes 5.0.9a
Excerpt from the Lotus Notes and Lotus Domino Release 5.0.9a MU fix list:
Client UI - Unread Marks
SPR# DKAZ53VS63 - Fixed a problem with unread processing to make it work
correctly when read documents replicate into a single database replica the user
already has open. If the user has two or more replicas open (including on
multiple machines), unread marks processing can still have problems.
Supporting Information:
When a database is opened, the table of NoteID's corresponding to unread
documents that are specific to the user's ID is loaded from the database,
cached in the DESKTOP.DSK, and then updated by the unread mark journal in the
CACHE.DSK (which maintains the most recent unread mark operations). When the
database is closed, the updated table is written back to the database.
If you are working with a server-based database, this allows messages
previously opened at one workstation to appear marked as read from the other
workstation. This also maintains consistency across different replicas of the
database. When the database is opened, this cached journal updates the
DESKTOP.DSK's loaded table of NoteID's corresponding to unread documents.
The problem comes into play when a local replica is used exclusively on a
secondary machine. Since replicating databases does not, by default, replicate
unread marks, when you replicate your mail via the Replicator tab, the client
is not actually opening the database on the server. Thus, any unread
operations that occur on the local replica that are stored in the journal are
not played back against the server replica.
Since the unread status of the saved sent message is not written back to the
server-based database from the unread mark table stored in the DESKTOP.DSK or
the unread journal, the document appears unread on the server when you get back
into the office. If you actually opened the server-based database from the
home machine, then the locally cached journal would update the Server
database's table, and the sent message would appear correctly as already read,
regardless of where it was opened.
Related Documents:
Unread Marks Are Not Exchanged Replicating to a Server From Two Different
Clients
Document #: 1093302
'Copy Into' Results in New Memo, Calendar Entry, or ToDo Marked as Unread for
Sender of New Item
Document #: 1090176
Saved Sent Mail Incorrecty Appears as Unread When Sent From iNotes Web Access
Document #: 1100202 More >
|  |
|
|
|
|
|